gh-155811: Add a seqcount to gc_stats to prevent torn reads - #155828

cc @sergey-miryanov @nascheme

I'm concerned that we now need to read memory three times with this approach:

struct gc_stats {
    uint32_t before_update_seq;
    struct gc_young_stats_buffer young;
    struct gc_old_stats_buffer old[2];
    uint32_t after_update_seq;
};

If before_update_seq and after_update_seq don't match, we have a torn read.

What do you think?

@sergey-miryanov I'd push back. :-)

successes=1966598 failures=191

is around ~200KHz.

I'm not sure if there's a guarantee about copy-order and monotonicity of process_vm_readv etc.

Also, assuming these guarantees, before_update_seq and after_update_seq might be racy? What if:

1. Reader read before_update_seq (0)
2. Writer incremented before_update_seq (1)
3. Reader read after_update_seq (0)
4. Writer incremented after_update_seq (2)

Yes, my variant will not work, I thought more about it - so drop it :)

What if:
Writer:

1. Move update_seq to the begin of struct
2. Write to update_seq

Reader:

1. Read gc_stats (update_seq + stats)
2. Read update_seq
3. Compare update_seq(1) and update_seq(2)

Even better, we could pack both counters into a single 32-bit integer — using the lower 16 bits for before and the upper 16 bits for after. This would let us read both values with a single atomic load.

What do you think?